United States Patent u?] 

Schneck et al. 



nuiiiiiiiiiiwniui 

US006108583A 
[li] Patent Number: 6,108,583 
[45] Date of Patent: *Aug. 22, 2000 



[54] ADAPTIVE DATA SECURITY SYSTEM AND 
METHOD 

[75] Inventors: * Phyllis A. Schneck, Potomac, M&; 

Karsten Sen wan, Tucker, Ga.; Santosh 
Chokhani, Arlington, Va. 

[73] Assignee: Georgia Tech Research Corporation, 
Atlanta, Ga. 

[ * ] Notice: This patent issued on a continued pros- 
ecution application filed under 37 CFR 
1.53(d), and is subject to the twenty year 
patent term provisions of 35 U.S.C. 
154(a)(2). 



[21] Appl. No.: 09/181,304 
[22] Filed: Oct. 28, 1998 

Related U.S. Application Data 
[60] Provisional application No. 60/063,551, Oct 28, 1997. 

[51] Int. CI. 7 G05B 15/02; G05B 19/18 

[52] U.S. CI 700/9; 700/7; 700/8; 700/68; 

700/67; 709/229; 709/230; 709/213; 713/186; 

713/187; 71.3/188 

[58] Field of Search 380/1, 2, 26, 30; 

713/186, 187, 188; 700/2, 8, 9, 68, 67; 

709/229, 230, 213 

[56] References Cited 

U.S. PATENT DOCUMENTS 

4,771,391 9/1988 Blasbalg 364/514 

4,965,827 10/1990 McDonald 380/25 

(List continued on next page.) 

OTHER PUBLICATIONS 

Meyer, et al., "MPEG-FAQ 4.1," Security Mechanisms for 
Multimedia-Data with the Example MPEG-I-Project, 
Project Description of SECMPEG, 1995, pp. 1-2. 



Jha, et al., "Adaptive Resource Allocation for Embedded 
Parallel Applications," Proceedings of the Third Interna- 
tional Conference on High Performance Computing, Dec. 
1996. 

Ivan-Rosu, et al., "Improving Protocol Performance by 
Dynamic Control of Communication Resources,'" Proceed- 
ings of the 2 nd IEEE Conference on Complex Computer 
Systems (ICECCS), Oct. 1996. 

Rosu, et aJ., "On Adaptive Resource Allocation for Complex 
Real-Time Applications," Proceedings of the 18th IEEE 
Real-Time Systems Symposium (RTSS), IEEE, 1997. 
Schneck, et al., "DRRM: Dynamic Resource Reservation 
Manager/' International Conference on Computer Commu- 
nications and Networks, IEEE, 1996. 

(List continued on next page.) 

Primary Examiner — Paul P. Gordon 
Assistant Examiner — Ramesh Patel 

Attorney, Agent, or Firm — -Thomas, Kayden, Horstemeyer 
& Risley, L.L.P. 

[57] ABSTRACT 

A system and method for data communication with adaptive 
security in wbich a send host transmits a data stream to a 
receive host in packets which contain an authentication data 
block with an authentication header and a signature block. 
The authentication header advantageously contains various 
fields including a verification type, a security algorithm, a 
minimum security level, a target security level, and an actual 
security level. The receive host adaptively performs verifi- 
cation of the data packets using varying security levels based 
in part on the availability of security operations per second 
(SOPS) in the receive host Where a data stream in the 
receive host is delayed by a security processing bottleneck, 
the receive host may alter the verification type, security 
algorithm, or the actual security level to speed up the 
processing of the data stream by reducing the amount of 
security processing performed. The receive host further 
allocates the SOPS among the data streams received based 
on a priority assigned to each data stream. 

34 Claims, 8 Drawing Sheets 
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ADAPTIVE DATA SECURITY SYSTEM AND 
METHOD 

CROSS-REFERENCE TO RELATED 
APPLICATIONS 

This application claims priority to and the benefit of 
copending U.S provisional patent application entitled 
"Authenticast: Adaptive Protocol to Enable Strong Authen- 
tication in High-Performance Applications" filed on Oct. 28, 
1997 and accorded Ser. No. 60/063,551, which is incorpo- 
rated herein by reference. 

STATEMENT REGARDING FEDERALLY 
SPONSORED RESEARCH OR DEVELOPMENT 

The U.S. government has a paid-up license in this inven- 
tion and the right in limited circumstances to require the 
patent owner to license others on reasonable terms as 
provided for by the terms of DAAH04-96- 1-0209 awarded 
by the U.S. Department of Defense. 

TECHNICAL FIELD 

The present invention is generally related to the field of 
data communications and, more particularly, is related to a 
system and method for securing data communication. 

BACKGROUND OF THE INVENTION 

Currently there is an exponential increase in the number 
of banks and other businesses that use the Internet to conduct 
transactions. The Internet is often a less expensive and less 
time consuming business medium than paper or the tele- 
phone. Electronic commerce and data interchange are 
increasing efficiency and giving companies a competitive 
edge in the global economy. With this growth in Internet 
electronic commerce, it becomes essential that greater secu- 
rity be provided for network-enabled transactions and col- 
laboration. 

The demand for information security is further elevated 
by the increasing prevalence of virtual private networks 
(VPNs), which are configurations by which private business 
is conducted over public media, such as the Internet. Sharing 
an existing public communications infrastructure is far more 
cost-effective than building a separate network for every 
business. However, security is required to create this "pri- 
vate" logical network over existing public wire. To create 
this VPN, security operations are invoked at both the source 
and destination nodes to ensure properties such as 
confidentiality, integrity, and authentication, for proof of 
origination and non-repudiation, of data. 

Although some Internet commerce applications have been 
developed, they do not provide sufficiently strong security 
for trusted transfer of private data over a public medium. The 
very essence of strong security is the notion that the security 
medium employed to protect data cannot be compromised in 
a sufficiently short time to allow use or alteration of those 
data by an unauthorized party. Therefore, data protection 
mechanisms for strong security are required to be complex, 
and they thus have a high computation overhead which 
detracts from overall application performance. In the interest 
of performance, security procedures are often omitted. If 
Internet commerce applications are to succeed, they cannot 
compromise performance or security. In the best possible 
case, security mechanisms would be transparent to users. 
However, so far, security in the world wide web security is 
poor. It is relatively few vendors that can delivery invisible 
security. The inherent tradeoffs in realizing both security and 
performance comprise the challenge we face in providing 
them. 
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In addition, law enforcement officials are becoming 
increasingly dependent on the availability of real-time, net- 
work collaborative and shared applications. For example, 
police officers are assisted by real-time photos and data 

5 delivered directly to their vehicles. This often requires 
strong authentication measures which are admissible in 
court as proof of origin, identity, and integrity of certain data 
and electronic evidence. The ability to dynamically vary 
levels of authentication to match available resources and 

io current requirements provides users of law enforcement 
applications options to employ strong security and use data 
as evidence while still receiving these data in a timely 
manner. This option was previously unavailable. 

In addition, the healthcare industry is another example of 

15 a business relying heavily on shared or collaborative appli- 
cations to provide greater customer service. For example, 
electronic communications infrastructures such as the Inter- 
net facilitate and expedite potentially worldwide collabora- 
tion on x-ray images or case studies. These materials, 

20 however, contain personal data, and for patient privacy and 
safety, are often required to be encrypted, for confidentiality 
and/or authenticated, for identification of the image. Again, 
security is necessary for these applications that enable the 
networked collaboration, yet the security could be detrimen- 

25 tal if it hampers the speed with which the information can be 
used to help the patient. 

SUMMARY OF THE INVENTION 

The present invention provides a system and method for 

30 facilitating adaptive security between a send host and a 
receive host. Briefly described, in architecture, the system 
includes a send host having a processor coupled to a data 
bus, a memory coupled to the data bus, an input device 
coupled to the data bus to input a desired security configu- 

35 ration for a data stream to be communicated to a receive 
host, and an output device coupled to the data bus to display 
the desired and actual security configurations for the data 
stream on an output display, the actual security configuration 
generally being received from the receive host. The proces- 

40 sor operates according to adaptive security logic stored on 
the memory which includes logic to generate a plurality of 
data packets associated with the data stream, the data 
packets including an authentication data block with an 
authentication header containing the actual security configu- 

45 ration and a signature. 

The system further includes a receive host which com- 
prises a processor, memory, data input, and data output, all 
coupled to a data bus. The data input is configured to receive 
at least one data stream comprising a number of data 

so packets, the data packets including an authentication data 
block having an authentication header and a signature. The 
processor runs according to adaptive security logic stored on 
the memory. The adaptive security logic includes logic to 
decompose an authentication header in the data packets, 

55 logic to perform a variable percentage verification on the 
data packets from the data stream, and logic to determine an 
actual verification percentage performed based on a number 
of available security operations, a minimum verification 
threshold, and a desired verification target, the minimum 

60 verification threshold and the desired verification target 
being contained in the authentication header. The adaptive 
security logic also includes logic to verify the data packets 
using delayed verification techniques. / 
The present invention can also be viewed as providing a 

65 method for communicating a data stream employing adap- 
tive security. In this regard, the method can be broadly 
summarized by the following steps: 
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identifying a desired verification type, a desired security 
algorithm, a minimum security level, and a target 
security level in a send host for communicating a data 
stream from the send host to a receive host; 

determining an actual verification type, an actual security 
algorithm, and an actual security level in the receive 
host based on the desired verification type, desired 
security algorithm, minimum security level, target 
security level, and an availability of a number of 
security operations per second (SOPS); 

communicating the actual verification type, the actual 
security algorithm, and the actual security level from 
the receive host to the send host; 

generating a plurality of data packets associated with the 
data stream in the send host, the data packets having an 
authentication data block with an authentication 
header, the authentication header containing the actual 
verification type, actual security algorithm, minimum 
security level, target security level, and the actual 
security level; 

verifying the data packets on a percentage basis if the 
actual verification type is percentage based verification, 
the percentage based verification being performed at 
the actual security level which is greater or equal to the 
minimum security level and less than or equal to the 
target security level; and 
performing a delayed verification on the data packets if 

the actual verification type is delayed verification. 
The present invention has numerous advantages, a few of 
which are delineated hereafter as merely examples. An 
advantage of the invention is that it facilitates more effective 
data security by allowing a receive host to adapt the security 
level at which a data stream is verified based upon the 
availability of host processor resources to provide security 
operations per second (SOPS) in the receive host. In this 
manner, data streams received by the receive host are not 
delayed or lost due to a security processing bottleneck which 
can occur if multiple incoming data streams stress the 
security operation capacity of a particular receive host. 

Other advantages of the invention include that it is user 
friendly, robust and reliable in operation, efficient in 
operation, and easily implemented for mass commercial 
production. 

Other features and advantages of the present invention 
will become apparent to one with skill in the art upon 
examination of the following drawings and detailed descrip- 
tion. It is intended that all such additional features and 
advantages be included herein within the scope of the 
present invention. 

BRIEF DESCRIPTION OF THE SEVERAL 
VIEWS OF THE DRAWINGS 

The invention can be better understood with reference to 
the following drawings. The components in the drawings are 
not necessarily to scale, emphasis instead being placed upon 
clearly illustrating the principles of the present invention. 
Moreover, in the drawings, like reference numerals desig- 
nate corresponding parts throughout the several views. 

FIG. 1 is a functional block diagram of an data security 
system according to an embodiment of the present inven- 
tion; 

FIG. 2 is a block diagram of the send host of FIG. 1; 
FIG. 3 is a flow chart showing the send host authentica- 
tion logic of FIG. 2; 

FIG. 4 is a drawing of the output display of FIG. 2; 
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FIG. 5 is a drawing of an authentication data block 
generated by the send host of FIG. 2; 

FIG. 6 is block diagram of the receive host of FIG. 1; 

FIG. 7 is a flow chart showing the receive host authen- 
s Ucation logic of FIG. 6; and 

FIG. 8 is a flow chart of a SOPS identification subroutine 
of FIG. 7. 

DETAILED DESCRIPTION OF THE 
10 INVENTION 

Turning to FIG. 1, shown is a functional block diagram of 
an authentication system 100 according to an embodiment of 
the present invention. The authentication system 100 

15 includes at least one send host 103 and a receive host 106. 
Although only a single send host 103 is shown, it is 
understood that multiple send hosts 103 may communicate 
with the receive host 106, the single send host 103 being 
shown for purposes of the following discussion. Likewise, 

20 the single send host 103 may communicate with multiple 
receive hosts 106, the single receive host 106 being shown 
for purposes of the following discussion as well. 
Additionally, multiple send hosts 103 may communicate 
with multiple receive hosts 106. 

25 The send host 103 generates a data block 109 or receives 
the data block 109 from a separate source to be communi- 
cated to the receive host 106. Generally, the data block 109 
is of a predetermined length and may be formed, for 
example, from a continuous data stream or data file received 

30 by the send host 103. The data block 109 is formed as the 
data payload in a packet to be communicated to the receive 
host 106 as will be discussed. 

The data block 109 may include any type of data such as, 
for example, but not limited to, audio, video, or other 

35 computer data. The send host 103 also includes a key 113 
which may be a block of data of predetermined length as is 
known in the art. The key 113 may be a private key for 
signing the data, or a public key for encrypting the data as 
known in the art. Note that other keys may be employed to 

40 accommodate different authentication or encryption algo- 
rithms. 

The send host 103 includes a signature generator 116 
which generates a signature block 119 from the data block 
45 109 and the key 113 using a predetermined security algo- 
rithm which may be, for example, but not limited to, a 
security algorithm such as the Digital Signature Algorithm 
(DSA), the Rivest-Shamir-Adleman (RSA) algorithm, or 
secret key authentication, which are generally known in the 

50 art - 

The send host 103 also includes an authentication header 
generator 123 which generates an authentication header 126. 
The authentication header 126 includes various data fields, 
such as, for example, an authentication sequence number, 

55 data frame size, frame type, security algorithm, verification 
type, minimum security level, target security level, and an 
actual security level. The receive host 106 employs these 
data fields to generate an actual security configuration to 
achieve authentication of a data stream communicated from 

6Q the send host 103. The actual security configuration is 
dynamic in that it may be changed by either the send host 
103 or the receive host 106 during the course of data 
communication therebetween in response to user or appli- 
cation requirements, or changes in computer resource avail - 

65 ability as will be discussed. 

The authentication header generator 123 may receive a 
desired security configuration from the user input 129 or a 
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default desired configuration may be received from a default 
storage 133 for a particular data stream. The desired security 
configuration is displayed on a display device 136 along 
with the actual security configuration which may ultimately 
be determined by the receive host 106 depending upon the 
specific desired security configuration specified by the user. 
Upon system startup, the default desired security configu- 
ration is obtained from the default storage 133 and displayed 
on the display device 133, A user may then alter the desired 
security configuration via the user input 129. 

The authentication header generator 123 generates the 
authentication header 126 which contains the actual security 
configuration to be placed in an authentication data block 
139. Together, the data block 109 and the authentication data 
block 139 make up a data packet 143 which is communi- 
cated to the receive host 106. The data stream is thus a 
continuous stream of "signed" data packets 143, each data 
packet 143 containing an authentication data block 139 with 
an authentication header 126 and a signature block 119. It 
may also be possible, however, that the data stream may 
only contain a predetermined percentage of "signed" data 
packets 143 as desired by the user. The security configura- 
tion identified in the authentication header 126 is initially 
determined from the desired security specification and may 
be altered based on feedback received from the receive host 
106. Note that the user may alter the desired security 
specification after data communication is commenced 
between the send host 103 and the receive host 106. The 
receive host 106 may also alter the actual security configu- 
ration based on the operating state of the receive host 106, 
the altered security configuration being displayed to the user 
on the display device 133. 

The receive host 106 receives the data packet 143 and the 
authentication header 126 is decomposed in an authentica- 
tion header decomposer 146 in which the above stated fields 
are separated from the data packet 143 for use by the receive 
host 106. The receive host 106 then attempts to execute the 
desired security verification configuration contained in the 
authentication header 126. The receive host 106 may employ 
one of several verification types. In the preferred 
embodiment, two specific verification types are used, 
namely, delayed authentication verification and percentage 
based verification, although other verification types may be 
employed as well. 

When delayed authentication is employed, a predeter- 
mined number of signature blocks 119 and corresponding 
data blocks 109 from the data packets 143 received are 
collected in a bundle 149 as indicated by a first functional 
switch 153 which is placed in the D position. Thereafter, the 
delay authentication verifier 156 operates on the bundle 153 
and verifies the data blocks 109 contained therein together 
using appropriate hashing functions known by those skilled 
in the art. Delayed verification will verify one hundred 
percent of the data packets. Once verified, the data blocks 
119 are then provided to the receive data processor 159 for 
further processing according to the specific application. 
Delayed authentication is almost always available as a 
verification option, even when security processing resources 
are limited as delayed authentication exploits hashing tech- 
niques that reduce a large amount of data to a relatively 
small amount which can be verified rather quickly, However, 
there is a greater probability of processing delay due to data 
corruption as many data blocks are verified at once, which 
means that a single corrupted data block would require the 
entire data block to be retransmitted for verification. 

When percentage based verification is employed, a pre- 
determined percentage of signature blocks 119 and corre- 



18,583 

6 

sponding data blocks 109 from the data packets 143 are 
accessed by a percentage authentication verifier 163 as 
indicated by the first functional switch 149 being placed in 
the P position. A second functional switch 166 provides 

5 . access to a particular signature block 119 and corresponding 
data block 109 upon which verification is performed when 
in the V position. Otherwise, when the second functional 
switch 166 is in the N position, the data block 109 is passed 
on to the receive data processor 159 without verification, the 
0 signature block 119 being discarded as shown. After a 
particular data block is verified by the percentage authenti- 
cation verifier 163, the verified data block 109 is provided to 
the receive data processor for further processing according 
to the specific application. Note that the frequency or actual 

15 security level at which the second functional switch 166 
provides access to the signature blocks 119 and correspond- 
ing data blocks 109 is determined by the security monitor 
169. Generally, the security levels as discussed herein refer 
to the percentage of verified data packets in the receive host 

w 106. The security monitor 169 also determines the verifica- 
tion type as indicated by the first functional switch 153, as 
well as the specific security algorithm employed by both the 
delayed authentication verifier 156 and the percentage 
authentication verifier 163. 

25 The security monitor 169 attempts to specify an actual 
verification type, actual security algorithm, and an actual 
security level according to the desired security configuration 
received from the send host 103. However, the receive host> 
106 may not have enough processor time or security opera - 

30 tions per second (SOPS) to provide the desired security 
configuration due to the verification of other data streams 
which currently employ much if not all of the SOPS avail- 
able in the receive host 106 at a given moment. 
Consequently, the security monitor 169 may force a changed 

35 in the verification type, security algorithm, and/or the actual \ 
security level that differs from the desired security configu- II 
ration received by the send host 103 in order to accommo-# 
date the data stream. ^ 
In order to change the security algorithm employed, the 

40 security monitor 169 sends the new security algorithm to be 
employed to the send host 103 via a return path, the 
authentication header generator 123 implementing the new 
security algorithm while changing the authentication header 
to indicate the new security algorithm appropriately. The 

45 security algorithm is changed in this manner because the 
generation of the signature block 119 is performed by the 
send host 103. 

Likewise, a change in the verification type is effected by 
the security monitor 169 by sending the new verification 

50 type to the send host 103 via the return path. The new 
verification type is then placed in the authentication header 
126 by the authentication header generator 123. When a data 
packet 143 containing the new verification type reaches the 
receive host 103, then the security monitor causes the first 

55 functional switch 153 to move to the D position to employ 
delayed authentication verification in synch with the incom- 
ing data packets 143 earmarked for such verification type. 

A change in the actual security level when percentage 
based verification is employed may occur in the receive host 

60 106 or the send host 103. In the receive host 106, the actual 
security level is raised or lowered based upon the number of 
SOPS available in the receive host 106. It is understood that 
a lower security level requires a correspondingly lower 
number of SOPS to implement and vice versa. Note that the 

65 actual security level is not lowered below a predetermined 
minimum security level which is identified in the authenti- 
cation header 126 so as to maintain a minimum amount of 
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security. The actual security level determined by the security configuration may include the desired security algorithm, 

monitor 169 is communicated to the send host 103 for the desired verification type, the minimum security level, the 

display on the display device 136. target security level, and the actual security levcL The actual 

The actual security level may be changed by the send host security level may initially be set equal to the target security 

103 by the user. Specifically, the user may adjust the actual S lcvel unlil mc recelve host 103 ***** mc actual security level 

security level via the user input 129. If the user adjusts the ^ to the lack of available processing resources to accom- 

actual security level to a point which the receive host 106 is P 1 ** * e 4 ^ 1 level. These parameters may imtiaUy 

unable to maintain due to a lack of SOPS availability, the * read from ' dehu ^ c ^ P™»«« «™& °° f 

receive host 106 may generally react by switching to data dev,ce 216 2 > ° r «mply entered by the 

delayed verification in which one hundred percent of the » user via ,k f m P u ' 1 . nt ? fi f c d , evice m Also dunng 

data packets are verified as delayed verification can gener- startup a data stream pr.on.y level is ; communicated from 

ally be performed with a minimal number of SOPS due to *">.»>°* 103 '° receive host 106 which is used by 

the hashing functions employed. I allocating processor resources or 

, , , . , „ , . SOPS to the number of data streams received at any given 

Note that when the receive host 106 alters any security momen , Note ^ mc riori , , evel alsQ be mdu( f ed as 

parameter due to a lack of available SOPS, the rece.ve host " a da(a fie]d in ^ au(henticalion header 126 (FIG 1} and 

106 may store the previous desired parameters in memory so ma ^ aUered b ^ ^ >t ^ ^ host m ^ riorf 

that the receive host may revert back to the previous desired leve , js ako ^ d on me ^ , device 136 

parameters when SOPS become available. fUese parameters b[ock ^ host 103 establishes 

may include, but are not limited to. the desired verification ■ *• v 1 - 4L iL ■ ■ ^m,/^ 

type and the desired security algorithm. *> J data commurucaUons link W!th the receive host 106 (FIG. 

/I L, . , . 1) undergoing an initial training procedure in which the 

The receive host 106 mcludes a receive host input 173 in dcskcd ^ QmiXy parameters are communica tcd from the send 

whicha user may alter the ^actud security parameters manu- host 1Q3 tQ ^ feceive host 106 llie reoeive host 106 

ally. The receive host 106 displays the desired and actual evaluates its [{ {Q vedfy ^ data kets 143 (nQ 1} 

security configuration on the receive display device 173 to ^ t0 be comrmJnicated according to the desired security 

be viewed by the user. configuration, and, if the receive host 106 has the necessary 

Note that the functionality of the send host 103 and the available SOPS, the verification of the data stream is per- 

receive host 106 as described above and in the following formed according to the desired security configuration. If the 

discussion may be resident in a single computer system requisite SOPS are not available, then the receive host 106 

which may act as a send host 103 or a receive host 106 at any 3Q will determine and send an actual security configuration 

given time, depending upon whether the user is sending or bac k to th e send host 103 if the desired security configura- 

receiving data. Further, a single computer system may tion allows such parameters to be varied by the receive host 

simultaneously act as a send host 103 and a receive host 106 106. The actual security configuration may include, for 

at the same time, communicating one or more data streams example, the actual security algorithm, the actual verifica- 

to a number of destination data endpoints and receiving one 35 ^ t yp e) anf j the actual security level. If the desired security 

or more data streams from other origination data endpoints. configuration does not allow such changes, then the data link 

All of the above functionality discussed herein is imple- will be rejected by the receive host 106. The actual security 

mented at a user/application level as known in the art which parameters are then displayed on the output display device 

provides a distinct advantage as the present invention may 130 (FIG. 2), if the data stream is accepted by the receive 

be employed regardless of the underlying physical layer 40 host 106. 

such as a network. The send host authentication logic 229 then progresses to 

Referring next, to FIG. 2, shown is block diagram of the block 309 in which the data packets 143 (FIG. 1) are 

send host 103 according to an example embodiment of the assembled with the authentication data block 139 (FIG. 1) 

present invention. Hie send host 103 includes a computer which includes the authentication header 126 (FIG. 1)" and 

system 203 with a processor 206 and a memory 209 which 45 the signature block 119 (FIG. 1). The signature block 119 

are electrically coupled to a data bus 213. Also electrically (FIG. 1) is generated using the actual security algorithm 

coupled to the data bus 213 are a data storage device 216, an which is the same as the desired security algorithm specified 

input interface 219, an output display interface 223, and a in the desired security configuration unless altered by the 

data communication interface 226. The input interface mod- receive host 106. The data packets 143 are communicated to 

ule 219 in turn is electrically coupled to a user input 50 the receive host 106. 

interface device 129 such as a keyboard, mouse, or other Next in block 313, the send host authentication logic 229 

suitable device. Likewise, the output display interface 223 is determines whether the desired security configuration has 

electrically coupled to an output display device 136 such as been changed by the user via the user input interface device 

a cathode ray tube (CRT) or suitable display device. The data 129 (FIG. 2). If such a change has been made, then the send 

storage device 216 may be a hard drive, floppy disk drive, 55 host authentication logic 229 progresses to block 316. If not, 

fixed memory device, or other suitable means of data then the send host authentication logic 229 progresses to 

storage. The data communication interface 226 allows the block 319. In block 319, the send host authentication logic 

send host 103 to communicate with the receive host 106 229 determines whether any of the actual security param- 

(FIG. 1) via a data communications channel (not shown). In eters have beea changed by the receive host 319. If such a 

performing the various tasks as discussed herein, the pro- 60 change has been made, then the send host authentication 

cessor 206 operates according to the send host authentica- logic 229 moves to block 316. In block 316, the desired and 

tion logic 229 stored on the memory 209. actual security parameters displayed by the output display 

Turning next to FIG. 3, shown is flow chart which depicts device 136 are altered to reflect any changes made, 

the send host authentication logic 229. The send host authen- Thereafter, the send host authentication logic 229 reverts 

tication logic 229 begins with block 303 in which the desired 65 back to block 309 in which the data packets 143 are 

security configuration is determined and displayed on the generated using the new security parameters. According to 

output display device 136 (FIG. 1). The desired security the preferred embodiment, the actual security level may be 
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altered by the send host 103 as initiated by the user, for 
example, whereas the verification type and the security 
algorithm may not be changed by the send host 103 after the 
startup of data communication because the receive host 106 
controls these parameters. 

If in block 319, the receive host 106 does not change any 
of the actual security parameters, then the send host authen- 
tication logic 229 progresses to block 323 where it is 
determined whether the transmission of the data stream is 
complete. If the transmission is not complete, the send host 
authentication logic 229 reverts back to block 309 to con- 
tinue to generate and communicate data packets. If the 
transmission of the data stream is complete in block 323, 
then the send host authentication logic 229 ends. Thus, the 
send host authentication logic 229 ultimately establishes an 
actual security configuration by which the data stream is 
communicated and reacts to any changes in the security 
parameters of the actual security configuration initiated by 
either the user or by the receive host 106. Id this manner, the 
security configuration adapts over time to facilitate optimum 
data transmission speed while providing adequate security. 

With reference to FIG. 4, shown is an output display 
screen 403 appearing on the output display device 136, 
which may be a CRT, for example, or other suitable display 
device or devices. The output display screen 403 includes a 
desired verification type block 406 in which one may toggle 
between delayed verification 409, percentage based verifi- 
cation 413, and automatic verification 416. Where delayed 
verification 409 or percentage based verification 413 are 
chosen, the receive host (FIG. 1) is forced to employ the 
desired verification type chosen and may not switch to an 
alternative verification type. Where automatic verification 
416 is chosen, the actual verification type can be determined 
by the receive host (FIG. 1) based on availability of SOPS, 
etc. Preferably, the receive host 106 will attempt to establish 
percentage based verification before delayed verification 
due to a greater reliability and a lesser susceptibility to 
delays, when the desired security configuration allows the 
receiver to select the verification type. Generally, delayed 
verification is employed when percentage based verification 
cannot be accommodated by the receive host 106. 

The output display screen 403 also includes a desired 
parameters block 419 which displays a desired security level 
range which includes a minimum security level 423 and a 
target security level 426 which may be entered with the user 
input interface 129 (FIG. 2) such as a keyboard for example. 
The desired parameters block 419 also includes a desired 
security algorithm 429 and a fixed block 433. The desired 
parameters block 419 may offer a pull down list of security 
algorithms within which one may chose a particular algo- 
rithm to be employed. The fixed block 433 indicates whether 
the receive host 106 may specify an actual security algo- 
rithm other than that chosen by the user as indicated by the 
desired security algorithm 429. 

The output display screen 403 also includes a security 
thermostat 436 which includes a slide control 443 that 
indicates the actual security level 439 between the minimum 
and target security levels 423 and 426. Note that the slide 
control may be moved up and down with, for example, a 
mouse which guides a pointer on the output display screen. 
Next to the security thermostat 436 is an actual parameters 
block 446 which shows an actual security algorithm 453 and 
an actual verification type 456. The actual security algorithm 
453 and the actual verification type 456 are those dictated by 
the receive host 106 (FIG. 1) based on SOPS availability. If 
enough SOPS are available to implement the desired 
parameters, then the parameters in the actual parameters 
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block 446 would mirror the desired parameters in the desired 
verification type block 406 and the desired parameters block 
419. 

In addition, the output display screen 403 features a data 

5 stream identifier block 459 in which includes a current data 
stream indicator 463 with toggle 'buttons 466. The toggle 
buttons 466 increase or decrease the value in the current data 
stream indicator 463. The current data stream indicator 463 
indicates the particular data stream for which parameters are 

10 displayed on the output display screen 403 at a given time 
in which the send host 103 is communicating two or more 
data streams to two or more receive hosts 106. 

The output display screen 403 includes a default configu- 
ration save button 469 which causes the current desired 

15 security parameters as reflected in the desired verification 
type block 406, the desired parameters block 419, and the 
security thermostat 436 to be saved to the data storage 
device 216. In the preferred embodiment, this default con- 
figuration is employed whenever a new data stream is 

20 initiated, where the various default parameters may be 
altered as the user sees fit. 

The output display screen further includes a packet signed 
percentage block 473 which indicates a percentage of data 
packets 109 (FIG. 1) for which a signature block 119 (FIG. 
1) is generated. This value may be less than one hundred 
percent when processor resources are stressed in the send 
host 106 (FIG. 1), thereby reducing the demand for proces- 
sor resources for the signature generation. 

30 Finally, the output display screen features a priority 
selection block 476 with a priority indicator 479 and priority 
indicator toggle buttons 483. The priority of a particular data 
stream may be chosen by the user by manipulating the toggle 
buttons 483 with a button on a mouse (not shown). In this 

35 manner, one may alter the priority of the particular data 
stream. 

Turning then, to FIG. 5, shown is the authentication data 
block 139. The authentication data block 139 includes the 
authentication header 126 with various data fields to com- 

40 municate the various security parameters discussed previ- 
ously as well as additional parameters. It is understood that 
the particular order and size of the data fields as shown 
herein is as an example as other sizes and orders may be 
employed. The authentication header 126 includes an 

45 authentication sequence number field 503 which uses bytes 
0-16. The authentication sequence number field 503 is 
employed to keep track of the order in which data packets 
are authenticated and received. Next, a data frame size field 
506 occupying bytes 17-20 is specified which indicates the 

50 size of the authentication data block 139. A frame type field 
509 which occupies the 21 st byte is specific to an encoding 
employed, for example, I, B, or P frames as in MPEG 
encoding, which is known in the art. 

Next, a security algorithm field 513 is specified in byte 23 

55 which indicates the actual security algorithm 513 employed 
by the receive host 106 (FIG. 1). In byte 24 is a verification 
type field 516 which indicates the actual verification type 
employed by the receive host 106. In byte 25, a security 
level minimum field 519 is defined which indicates the 

60 minimum security level or verification percentage to be 
performed by the receive host 106. Note that the minimum 
security level can not be changed by the receive host 106 so 
that a minimum level of verification is maintained as desired 
by the user. Next is a target security level field 523 which 

65 occupies byte 25 and specifies the target security level. The 
target security level is set by the send host 103 while the 
receive host 106 attempts to meet this leveL The target 
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security level field 523 is followed by an actual security Thereafter, the receive host verification logic 619 

level field 526 which occupies byte 26 of the authentication progresses to block 716 where the tracking table is consulted 

data block 139. The actual security level 526 may be to determine how many SOPS are available to accommodate 

determined by the receive host 106 in light of available the potential new data stream or the desired change in the 

processor resources, or the user at the send host 103 may 5 aclua ] security level. In particular, the receive host verifica- 

manually change the actual security level 526 via the ^ logic 619 iden tifies how many unused SOPS are avail- 

secunty ^ermostat 436. Byte 27 is occupied by a priority able m6 how many non^ca] S 0?S may be diverted from 

field 529 which holds the actujd priority assigned to the data ^ vcrification proccssmg of olhcr 

data streams to facilitate 

f» m ^ y ' te signature bock 119 follows the priority ^ ^ new d s(ream 0f ^ ch fa ^ ^ 

field 529 and is of variable length depending upon the , , KT ... , crmc 4 . j , ^ 

particular security algorithm employed. 10 secunt y °vel. Non-cnUcal SOPS are those used to perform 

rr* ^ / pro , * 1.1 i j- r.u a percentage based verification at an actual security level 

Turning next to FIG. 6, shown is a block diagram of the , . & , tU - . , ; f . 

receive host 106 (FIG. 1). THe receive host 106 is comprised whl , ch * f* ait < than J 16 , m " umum for a 
of a computer s^tem 603 which includes a processor 606, P**»l" da * a s * ea *- Th J is to say, non-cntical SOPS may 
a memory 609, and a data communication interface 613. The be dlverted from * e ve n fi canon processing of a particular 
processor 606, memory 609, and data communication inter- 15 dala stream and me minimum security level can be mam- 
face 613 are all electrically coupled to a data bus 616. The lained for mat data stream - 

processor 606 operates according to receive host verification The receive host verification logic 619 then progresses to 

logic 619 stored on the memory 609. The data communica- block 719 in which it is determined whether there are 

tion interface 613 is adapted to be electrically coupled to a enough unused SOPS and non-critical SOPS as indicated by 

number of channels 623 through which the receive host 106 20 the tracking table which may be diverted to accommodate 

may communicate with any number of send hosts 103. The the new data stream or the security parameter change. If 

receive host 106 further includes a data storage device 626, sucn ^ tne casc> mcr i the receive host verification logic 619 

an input interface 629, and an output display interface 633, proceeds to block 723. If not, then the new data stream is 

all of which are electrically coupled to the data bus 616. The rejected and/or lhc sccurity parameler change is not 

input interface 629 is also electrically coupled to receive M mented and tfae receiye host verification , ic 619 reverts 

host input interface device 173 such as a keyboard or mouse. * n 7 ni nv,, „„„ ,„ - P „„„ nita ° , tn • 

. . . . . , • i . • ii back to blocK 70 J. For example, it one attempts to increase 

Similarly, the output display interface 633 is electrically . , , i . ■ w t , 

i j * *u • j- i j • u u the actual security level by manipulating the security ther- 

coupled to the receive display device 176 which may be a # # /T ^~ J AS . r . . 6 , .„ J 

/-n4- «u wi a • 'in. a- i a • i nc mostat 436 (FIG. 4), then the receive host 106 will attempt 

CRT or other similar device. The receive display device 176 A c M . A , \, . " . A , ^_ . . . , T ~ * 

c . 4 , . * a' i am /tt/1 a\ ; * r iL to facilitate the increase in the actual security level If the 

features the output display screen 403 (FIG. 4) to inform the , n . 4 ... . . , 

j * 4 . *• r *i_ • , ; 1ft , JU receive host 106 cannot achieve the higher security level 

end user of the operation of the receive host 106. , , , A . • . . 

n c . . -.^ - i . a . . ■ , using percentage based verification, then the receive host 

Referring then, to FIG. 7, shown is a flow chart which * .• n •» u *u *• 

. . . 6 . * rt r„ . 106 may automatically switch the verification type to 

depicts the receive host verification logic 619. The receive . , , A - c . . . , , f 

. , vc . - ^n. . . . , , • # . j delayed venncation to accommodate a security level of one 

host verification logic 619 begins with block 703 in which . „ i A . 

• i t. ^ ^ /r-r^, hundred percent, 

it is ascertained whether a particular send host 103 (FIG. 1) 35 

is attempting to establish secure data communication with ^ bIock 723 > me P reviousl y identified nonncnUcal SOPS 

the receive host 106 (FIG. 1). If so, the receive host and any unused SOPS are diverted to accommodate the new 

verification logic 619 progresses to block 706 in which in data stream and/or ^ sccunt y P arameter chan 5 e - ^ 

which the receive host 106 is provided with the priority tracking table is updated with the new allocation for each 

value for the data stream and the desired parameters includ- 40 altered data stream "fh"^ ^ new da t^ stream if one is 

ing the security algorithm, verification type, minimum and implemented. Thereafter, ^the receive host verification logic 

target security levels, and an initial actual security level 723 P ro ^* esses to block 726 - 

which may equal, for example, the target security level. Referring back at block 713, if there is not change to the 
Thereafter, the receive host verification logic 619 proceeds security parameters, then the receive host verification logic 
to block 709. 45 619 proceeds to block 729 in which it is determined whether 
If in block 703 there is no new data stream to be received, ^ communication of any current data stream has termi- 
then the receive host verification logic 619 proceeds to block nated * If ^ ch * not me casc > ^ receive host verifi- 
713 in which it is determined if any of the desired security cation lo S ic 619 reverts back to block 703 - If a current dala 
parameters, specifically the actual security level, has been stream has ceased communication in block 729, then the 
changed by the user at the send host 103. If any security 50 receive nost vacation logic 619 progresses to block 733. 
parameters have changed, then the receive host verification In block 733 » the sops which werc employed in processing 
logic 619 moves to block 709. me now terminated data stream are reallocated to the exist- 
In block 709, the receive host verification logic 619 m S data streams to maximize security for all of the data 
evaluates either the potential new data stream based on the streams ' Thereafter, the receive host verification logic 619 
parameters received in block 706, or the change in the actual 55 coaUniies t0 bIock 726 

security level or other security parameters detected in block * Q block 726, the security parameters for all data streams 

713 to determine how many SOPS are required by the new which are new or altered due to the allocation or reallocation 

data stream or the security parameter change in an existing °f lne SOPS in blocks 723 and 733 are communicated to 

data stream. Generally, such information is stored in a their respective send host(s) 103. Next, in block 736, the 

tracking table in the memory 609 that may include values 60 verification of the data packets of the current data streams 

which indicate the data stream priority, an amount of SOPS arc performed according to the security parameters deter- 

necessary to maintain the minimum security level, the mined for each data stream. Thereafter, the receive host 

amount of SOPS consumed to maintain the actual security verification logic 619 reverts back to block 703. 

level, and the amount of SOPS necessary to achieve the Note that the receive host verification logic 619 operates 

target security level for each existing data stream received 65 in a continuous loop searching for changes in the status quo 

by the receive host. The tracking table may also be stored on of the processing of the data streams and reacts to changes 

the data storage device 626 or other suitable storage device. by either reallocating processor resources (SOPS) to accom- 
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modate a change, or rejecting such changes altogether and 
maintaining the status quo. 

Finally, referring to FIG. 8, shown is a flow chart of the 
non-critical SOPS identification subroutine 716. The sub- 
routine 716 executes the logical steps taken in identifying 5 
non-critical SOPS with which to accommodate a change in 
security parameters of an existing data stream or to accom- 
modate a new data stream. Beginning with block 803, the 
resource tracking table is consulted looking for predeter- 
mined existing data streams with a priority that is equal to 10 
or lower than the priority of the new data stream or the 
changed data stream are examined to determine the quantity 
of non-critical SOPS in each. The predetermined number of 
lower priority data streams may be, for example, a pre- 
defined number of data streams starting from the lowest 15 
priority up, or the predetermined number of lower priority 
data streams may be determined at random. The predeter- 
mined number of data streams examined may include all of 
the lower priority data streams if there are not too many to 
examine. 20 

Next, in block 806 if a new data stream is sought to be 
implemented, then the subroutine 716 progresses to block 
809. If a new data stream is not to be implemented in block 
806, then the subroutine 716 ends. In block 809, predeter- 
mined data streams with a higher priority than the new data 25 
stream are examined for non-critical SOPS. The predeter- 
mined data streams examined may be, for example, a 
specific number of data streams starting from the highest 
priority down, or a random sampling of the higher priority 
data streams. The predetermined number of data streams 30 
examined may include all of the higher priority data streams 
if there are not too many to examine within an acceptable 
time period. Thereafter, the subroutine ends. 

Note that both the send host authentication logic 229 and 3S 
the receive host verification logic 619 of the present inven- 
tion can be implemented in hardware, software, firmware, or 
a combination thereof. In the preferred embodiments), both 
the send host authentication logic 229 and the receive host 
verification logic 619 are implemented in software or firm- 4Q 
ware that is stored in a memory and that is executed by a 
suitable instruction execution system. 

The flow charts of FIGS. 3, 7, and 8 show the architecture, 
functionality, and operation of a possible implementation of 
the adaptive security software employed by the send host 45 
103 (FIG. 2) and the receive host 106 (FIG. 6). In this regard, 
each block represents a module, segment, or portion of code, 
which comprises one or more executable instructions for 
implementing the specified logical function(s). It should also 
be noted that in some alternative implementations, the 50 
functions noted in the blocks may occur out of the order 
noted in FIGS. 3, 7, and 8. For example, two blocks shown 
in succession in FIGS. 3, 7, and 8 may in fact be executed 
substantially concurrently or the blocks may sometimes be 
executed in the reverse order, depending upon the function- 55 
ality involved, as will be further clarified hereinbelow. 

In addition, the send host authentication logic 229 (FIG. 
3) and the receive host verification logic 619 (FIGS. 7 and 
8), each of which comprise an ordered listing of executable 
instructions for implementing logical functions, can be 60 
embodied in any computer-readable medium for use by or in 
connection with an instruction execution system, apparatus, 
or device, such as a computer-based system, processor- 
containing system, or other system that can fetch the instruc- 
tions from the instruction execution system, apparatus, or 65 
device and execute the instructions. In the context of this 
document, a "computer-readable medium" can be any 
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means that can contain, store, communicate, propagate, or 
transport the program for use by or in connection with the 
instruction execution system, apparatus, or device. The 
computer readable medium can be, for example but not 
limited to, an electronic, magnetic, optical, electromagnetic, 
infrared, or semiconductor system, apparatus, device, or 
propagation medium. More specific examples (a nonexhaus- 
tive list) of the computer-readable medium would include 
the following: an electrical connection (electronic) having 
one or more wires, a portable computer diskette (magnetic), 
a random access memory (RAM) (magnetic), a read-only 
memory (ROM) (magnetic), an erasable programmable 
read-only memory (EPROM or Flash memory) (magnetic), 
an optical fiber (optical), and a portable compact disc 
read-only memory (CD ROM) (optical). Note that the 
computer-readable medium could even be paper or another 
suitable medium upon which the program is printed, as the 
program can be electronically captured, via for instance 
optical scanning of the paper or other medium, then 
compiled, interpreted or otherwise processed in a suitable 
manner if necessary, and then stored in a computer memory. 

Many variations and modifications may be made to the 
above-described embodiments) of the invention without 
departing substantially from the spirit and principles of the 
invention. All such modifications and variations are intended 
to be included herein within the scope of the present 
invention. 

What is claimed is: 

1. A send host employing adaptive security, comprising: 
a processor coupled to a data bus; 

a memory coupled to the data bus; 

an input device coupled to the data bus to input a desired 
security configuration for a data stream to be commu- 
nicated to a receive host; 

an output device coupled to the data bus to display an 
actual security configuration for the data stream, the 
actual security configuration being received from the 
receive host; and 

adaptive security logic stored on the memory and execut- 
able by the processor, the adaptive security logic 
including logic to generate a plurality of data packets 
associated with the data stream, the data packets 
including an authentication data block with an authen- 
tication header containing the actual security configu- 
ration and a signature, the actual security configuration 
being based upon a number of available security opera- 
tions in the receive host. 

2. The send host of claim 1, wherein the desired security 
configuration is displayed on the output device. 

3. The send host of claim 1, wherein the actual security 
configuration is displayed on the output device. 

4. The send host of claim 1, wherein the minimum 
verification level in the authentication header indicates a 
minimum percentage of the data packets that are decrypted. 

5. The send host of claim 1, wherein the minimum 
verification level in the authentication header indicates a 
minimum percentage of the data packets that arc authenti- 
cated to verify a source of the data packets. 

6. A send host employing adaptive security, comprising: 
a processor coupled to a data bus; 

a memory coupled to the data bus; 

an input device coupled to the data bus to input a desired 
security configuration for a data stream to be commu- 
nicated to a receive host; 

an output device coupled to the data bus to display an 
actual security configuration for the data stream, the 
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actual security configuration being received from the 
receive host; and 
adaptive security logic stored on the memory and execut- 
able by the processor, the adaptive security logic 
including: s 
logic to generate a plurality of data packets associated 
with the data stream, the data packets including an 
authentication data block with an authentication 
header containing the actual security configuration 
and a signature; and 10 
security thermostat logic to control an actual security 
level, the actual security level being included in the 
authentication header. 

7. A send host employing adaptive security, comprising: 

a processor coupled to a data bus; 15 

a memory coupled to the data bus; 

an input device coupled to the data bus to input a desired 
security configuration for a data stream to be commu- 
nicated to a receive host; 

an output device coupled to the data bus to display an 20 
actual security configuration for the data stream, the 
actual security configuration being received from the 
receive host; and 

adaptive security logic stored on the memory and execut- 
able by the processor, the adaptive security logic 25 
including: 

logic to generate a plurality of data packets associated 
with the data stream, the data packets including an 
authentication data block with an authentication 
header containing the actual security configuration 30 
and a signature; and 

logic to place a minimum security level in the authen- 
tication header. 

8. A send host employing adaptive security, comprising: 

a processor coupled to a data bus; 35 

a memory coupled to the data bus; 

an input device coupled to the data bus to input a desired 
security configuration for a data stream to be commu- 
nicated to a receive host; 

40 

an output device coupled to the data bus to display an 
actual security configuration for the data stream, the 
actual security configuration being received from the 
receive host; and 

adaptive security logic stored on the memory and execut- 45 
able by the processor, the adaptive security logic 
including logic to generate a plurality of data packets 
associated with the data stream, the data packets 
including an authentication data block with an authen- 
tication header containing the actual security confirma- 5Q 
tion and a signature, wherein the desired security 
configuration comprises a desired verification type, a 
minimum security level, a target security level, a secu- 
rity algorithm, and an actual security level. 

9. A receive host employing adaptive security, compris- 55 

ig: 

a processor coupled to a data bus; 

a memory coupled to the data bus; 

a data communications interface coupled to the data bus, 
the data communications interface being configured to 60 
receive at least one data stream comprising a number of 
data packets, the data packets including an authentica- 
tion data block, the authentication data block having an 
authentication header and a signature; and 

adaptive security logic stored on the memory and execut- 65 
able by the processor, the adaptive security logic 
including logic including: 
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logic to decompose the authentication header in the 
data packets; 

logic to perform a variable percentage verification on 
the data packets from the data stream; and 

logic to determine an actual verification percentage 
performed based on a number of available security 
operations in the receive host, a minimum security 
level, and a target security level, the minimum secu- 
rity level and the target security level being con- 
tained in the authentication header. 

10. The receive host of claim 9, wherein the logic to 
determine an actual security level further comprises logic to 
determine the number of available security operations by 
examining the at least one data stream received by the data 
communications interface for a non-critical processor time 
usage. 

11. The receive host of claim 9, wherein the adaptive 
security logic further comprises: 

logic to perform a delayed verification on a bundle of data 
packets from the data stream; and 

logic to enable one of the delayed verification and the 
variable percentage verification based on a verification 
type field contained in the authentication header and on 
the number of available security operations in the 
receive host. 

12. The receive host of claim 9, wherein the adaptive 
security logic further comprises logic to maintain a resource 
tracking table which indicates the number of security opera- 
tions required to accomplish the minimum security level, the 
target security level, and the actual security level, as well as 
a priority level of the at least one data stream. 

13. The receive host of claim 9, wherein the logic to 
perform a variable percentage verification on the data pack- 
ets from the data stream further comprise logic to decrypt a 
variable percentage of the data packets. 

14. The receive host of claim 9, wherein the logic to 
perform a variable percentage verification on the data pack- 
ets from the data stream further comprise logic to authen- 
ticate a variable percentage of the data packets. 

15. A send host employing adaptive security, comprising: 
means for inputting a desired security configuration for a 

data stream to be communicated to a receive host; 

means for displaying the desired security configuration 
and an actual security configuration for the data stream, 
the actual security configuration being received from 
the receive host; and 

means for generating a plurality of data packets associated 
with the data stream, the data packets including a data 
block and an authentication data block having an 
authentication header containing the actual security 
configuration and a signature the actual security con- 
figuration being based upon a number of available 
security operations in the receive host. 

16. A receive host employing adaptive security, compris- 
ing: 

means for receiving at least one data stream comprising a 
number of data packets, the data packets including an 
authentication data block, the authentication data block 
having an authentication header and a signature; 

means for decomposing the authentication header in the 
data packets; 

means for performing a percentage based verification on 
the data packets from the data stream; means for 
determining an actual security level performed based 
on a number of available security operations, a mini- 
mum security level, and a target security level, and a 
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desired actual security level, the minimum security 
level and the target security level being contained in the 
authentication header; and 
means for communicating the actual security level to a 
send host. 

17. The receive host of claim 16, wherein the means for 
determining an actual security level further comprises means 
for determining the number of available security operations 
by examining a resource tracking table for a non-critical 
processor time usage of at least one existing data stream. 

18. The receive host of claim 16, further comprising: 
means for performing a delayed verification on a bundle 

of data packets from the data stream; and 
means for enabling one of the delayed verification and the 
variable percentage verification based on a verification 
type field contained in the authentication header and on 
the number of available security operations in the 
receive host. 

19. A method for communicating a data stream employing 
adaptive security, comprising the steps of: 

identifying a desired verification type, a desired security 
algorithm, a minimum security level, a target security 
level, and a desired actual security level in a send host 
for communicating a data stream from the send host to 
a receive host; 

determining an actual verification type, an actual security 
algorithm, and an actual security level in the receive 
host based on the desired verification type, desired 
security algorithm, minimum security level, target 
security level, and a number of available security 
operations; 

communicating the actual verification type, the actual 
security algorithm, and the actual security level from 
the receive host to the send host; 

generating a plurality of data packets associated with the 
data stream in the send host, the data packets having an 
authentication data block with an authentication 
header, the authentication header containing the actual 
verification type, actual security algorithm, minimum 
security level, the target security level, and the actual 
security level; 

verifying the data packets using percentage based verifi- 
cation if the actual verification type is percentage based 
verification, the percentage based verification being 
performed at the actual security level which is greater 
than or equal to the minimum security level and less 
than or equal to the target security level; and 

performing a delayed verification on the data packets if 
the actual verification type is delayed verification. 

20. The method of claim 19, further comprising the step 
of altering the actual security level in the send host using a 
security thermostat 

21. The method of claim 19, further comprising the step 
of identifying the number of available security operations by 
identifying a number of non-critical security operations 
employed by a plurality of second data streams received by 
the receive host, and by identifying a number of unused 
security operations in the receive host. 

22. A computer program embodied on a computer- 
readable medium for operation in a send host to facilitate 
data communication with adaptive security, comprising: 

logic to input a desired security configuration for a data 
stream lo be communicated to a receive host; 

logic to display a desired security configuration and an 
actual security configuration for the data stream, the 



10 



20 



25 



30 



35 



45 



50 



55 



60 



65 



actual security configuration being received from the 
receive host; and 
logic to generate a plurality of data packets associated 
with the data stream, the data packets including an 
authentication data block having an authentication 
header containing the actual security configuration and 
a signature, the actual security configuration being 
based upon a number of available security operations in 
the receive host. 

23. A computer program embodied on a computer- 
readable medium for operation in a receive host to facilitate 
data communication with adaptive security, comprising: 

logic to receive at least one data stream comprising a 
number of data packets, the data packets including an 
authentication data block, the authentication data block 
having an authentication header and a signature; 

logic to decompose the authentication header in the data 
packets; 

logic to perform a percentage based verification on the 
data packets from the data stream; 

logic to determine an actual security level performed 
based on a number of available security operations in a 
receive host, a minimum security level, and a target 
security level, the minimum security level and the 
target security level being contained in the authentica- 
tion header; and 

logic to communicate the actual security level to a send 
host 

24. The computer program embodied on a computer- 
readable medium of claim 23, wherein the logic to determine 
the actual security level further comprises logic to determine 
the number of available security operations by examining a 
resource tracking table for a non-critical processor time 
usage of at least one existing data stream. 

25. The computer program embodied on a computer- 
readable medium of claim 23, further comprising: 

logic to perform a delayed verification on a bundle of data 
packets from the data stream; and 

logic to enable one of the delayed verification and the 
variable percentage verification based on a verification 
type field contained in the authentication header and on 
the number of available security operations in the 
receive host. 

26. A computer program embodied in a modulated data 
signal for transmission across a network, the computer 
program being for operation in a send host to facilitate data 
communication with adaptive security, comprising: 

logic to input a desired security configuration for a data 
stream to be communicated to a receive host; 

logic to display the desired security configuration and an 
actual security configuration for the data stream, the 
actual security configuration being received from the 
receive host; and 

logic to generate a plurality of data packets associated 
with the data stream, the data packets including an 
authentication data block having an authentication 
header containing the actual security configuration and 
a signature, the actual security configuration being 
based upon a number of available security operations in 
the receive host. 

27. A computer program embodied in a modulated data 
signal for transmission across a network, the computer 
program being for operation in a receive host to facilitate 
data communication with adaptive security, comprising: 

logic to receive at least one data stream comprising a 
number of data packets, the data packets including an 
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authentication data block, the authentication data block 
having an authentication header and a signature; 
logic to decompose the authentication header in the data 
packets; 

logic to perform a percentage based verification on the 
data packets from the data stream; 

logic to determine an actual security level performed 
based on a number of available security operations, a 
minimum security level, and a target security level, the 
minimum security level, the target security level being 
contained in the authentication header; and 

logic to communicate the actual security level to a send 
host. 

28. The computer program embodied in a modulated data 
signal of claim 27, wherein the logic to determine an actual 
security level further comprises logic to determine the 
number of available security operations by examining said at 
least one data stream received by the input device for a 
non-critical processor time usage. 

29. The computer program embodied in a modulated data 
signal of claim 27, further comprising: 

logic to perform a delayed verification on a bundle of data 

packets from the data stream; and 
logic to enable one of the delayed verification and the 

variable percentage verification based on the number of 

available security operations and on a verification type 

in the authentication header. 

30. A send host employing adaptive security, comprising: 
logical circuitry to input a desired security configuration 

for a data stream to be communicated to a receive host; 

logical circuitry to receive an actual security configuration 
for the data stream, the actual security configuration 
being received from the receive host, the actual security 
configuration being based upon a number of available 
security operations in the receive host; and 

logical circuitry to generate a plurality of data packets 
associated with the data stream, the data packets 
including a data block and an authentication data block 
having an authentication header containing the actual 
security configuration and a signature. 

31. A receive host employing adaptive security, compris- 
ing: 

logical circuitry to receive at least one data stream com- 
prising a number of data packets, the data packets 



including an authentication data block, the authentica- 
tion data block having an authentication header and a 
signature; 

logical circuitry to decompose the authentication header 
5 in the data packets; 

logical circuitry to perform a percentage based verifica- 
tion on the data packets from the data stream; 
logical circuitry to determine an actual security level 
10 performed based on a number of available security 
operations, a minimum security level, and a target 
security level, and a desired actual security level, the 
minimum security level and the target security level 
being contained in the authentication header; and 
logical circuitry to communicate the actual security level 
to a send host. 

32. A receive host employing adaptive security, compris- 
ing: 

a processor coupled to a data bus; 
a memory coupled to the data bus; and 
a data communications interface electrically coupled to 
the data bus, the data communications interface being 
configured to receive at least one data stream compris- 
ing a number of data packets; 
adaptive security logic stored on the memory and execut- 
able by the processor, the adaptive security logic 
including: 

30 logic to determine a number of available security 
operations in the receive host; and 
logic to allocate the number of available security opera- 
tions in the receive host to perform a verification of 
a number of the data packets in the at least one data 

35 stream. 

33. Hie receive host of claim 32, wherein the logic to 
determine a number of available security operations in the 
receive host further comprises logic to determine the number 
of available security operations based upon a priority 

40 assigned to the at least one data stream. 

34. The receive host of claim 32, wherein the logic to 
determine a number of available security operations in the 
receive host further comprises logic to determine a number 
of non-critical security operations. 
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